Remerciements
À faire à la dernière minute…
Préface
Exemple de préface…
Introduction
1. Avant-propos
1.1. Sur ce document
1.1.1. A qui est destiné ce document?
Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de support à leur cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!
1.1.2. A qui n’est-il pas destiné?
Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :
1.1.3. Historique
Ce document est la compilation de plusieurs années d’enseignement de SysML™ depuis 2007, que ce soit :
-
au Master TI, de l’Université de Pau et des Pays de l’Adour (cours d’introduction avec mon collègue et ami Nicolas Belloir),
-
au Master Recherche SAID, de l’UPS (introduction),
-
au Master ICE de l’Université de Toulouse II - Le Mirail (introduction avec mon collègue et ami Pierre de Saqui Sannes),
-
au Master of Science de Göteborg, Suède (introduction réalisée par mon collègue et ami Nicolas Belloir),
-
à l’Universitad Autónoma de Guadalajara, au Mexique (40h de formation professionnelle à des employés de Continental Mexique),
-
ou plus récemment au Master DL-SI de l’UPS.
Vous trouverez en référence (cf. Références) les ouvrages et autres documents utilisés.
1.2. Sur l’auteur
Voici quelques informations me concernant (pour peu que cela vous intéresse) :
-
Professeur à l’Univesité de Toulouse
-
Co-fondateur de l’association SysML-France en 2009
-
Membre du comité éditorial de la revue SoSyM depuis sa création en 2002
-
Membre du Steering Committee de la conférence ACM/IEEE MODELS depuis 2008
-
Enseignant en modélisation depuis 1995
-
Marié, une (merveilleuse) fille
1.3. Comment lire ce document?
1.3.1. Version électronique
Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.
|
|
Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, mais n’hésitez pas à en consulter la version électronique! |
1.3.2. Conventions typographiques
J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’http://www.methods.co.nz/asciidoc[AsciiDoc] :
-
des mises en formes particulières (e.g.,
NomDeBlocpour un élément de modèle), -
des références bibliographiques, présentées en fin de document (cf. Références),
-
tous les flottants (figures, tableaux) sont listés à la suite de la table des matière,
-
les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Requirements).
Le titre des figures indique (entre parenthèses)
un R pour les figures issues de Rhapsody,
un T pour les figures issues de TOPCASED,
un M pour les figures issues de MagicDraw,
et un UK pour les figures en anglais. Pour les conventions (de nommage notamment), cf. [conventions].
Pour les notes, conseils, avertissements, etc. voici la liste des pictogrammes utilisés :
|
|
Les notes comme celles-ci sont utilisées pour indiquer des éléments intéressant pour la majorité des lecteurs. |
|
|
Ces notes indiquent des points importants qui réclament votre attention. |
|
|
Celles-ci concernent en général des points de détail et permettent "d’aller plus loin". |
|
|
Définition : Exemple (OMG SysML v1.3, p. 152)
Ces notes concernent des définitions tirées de la spécification SysML™ et sont donc précisément référencées. |
|
|
Convention : Titre du conseil spécifique
Conseil spécifique aux formateurs. Comme ces conseils viennent pour la plupart de mes discussions avec les membres de l’UPSTI, j’ai choisi leur logo pour leur faire un clin d’oeil. |
|
|
Modélisation SysML incorrecte. |
|
|
Modélisation SysML partiellement correcte ou pouvant prêter à confusion. |
|
|
Modélisation SysML correcte. |
1.3.3. Pourquoi parler de "document"?
Parce que j’ignore la version que vous êtes en train de lire. À partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :
1.3.4. Utilisation et autres mentions légales
N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant à bruel@irit.fr.
1.4. Méthode pour cet ouvrage
C’est à l’heure du commencement qu’il faut tout particulièrement veiller à ce que les équilibres soient précis.
— Princesse Irulan
Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :
- La répétition
-
Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant. Ces répétitions sont limitées dans la version livre de cet ouvrage (car toute longueur inutile a un coût dans ce cas).
- L’illustration
-
Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés. Vous trouverez donc plus d’exemples que de définitions.
- Le référencement
-
Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.
- La "carte de base"
-
J’aime réaliser une "carte" [1] qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.
Aucune connaissance particulière {l’http://www.uml.org/[d’UML™] n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :
2. C’est quoi SysML?
Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.
2.1. Fiche d’identité
2.2. SysML, c’est…
- Un ensemble de 9 types de diagrammes
-
-
Diagrammes structuraux
-
Diagrammes de définition de blocs (
bdd) -
Diagrammes internes de blocs (
ibd) -
Diagrammes paramétriques (
par) -
Diagrammes de packages (
pkg)
-
-
Diagrammes comportementaux
-
Diagrammes de séquence (
sd) -
Diagrammes d’activité (
act) -
Diagrammes de cas d’utilisation (
uc) -
Diagrammes d'états (
stm)
-
-
Diagramme d’exigence (
req)
-
- Un profil UML™
-
C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML™. Un exemple : le
blocSysML™ n’est qu’une redéfinition de laclasseUML™. - Une notation
-
Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.
2.3. SysML, ce n’est pas…
- Une méthode
-
En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML™ ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
- Un outil
-
Nous verrons en effet que SysML™ ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.
- Un raton laveur
-
C’est juste pour voir ceux qui suivent.
|
|
On ne dit pas "le SysML" mais tout simplement "SysML". |
2.4. Références et liens utiles
Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. Liens et références utiles) et de références (cf. Références). Sinon, vous pouvez aussi constatez les évolutions de l’intérêt pour SysML™ grâce aux "trends". Voici les dernières tendances au moment où nous écrivons ces lignes[2] :
|
|
On y voit les journées SysML 2012 (Toulouse et Mulhouse). |
À noter également que l’OMG™ a réalisé en 2009 une enquête sur l’utilisation de SysML™ (cf. [OMG2009]) dont voici deux extraits :
3. À propos du Bac STI2D et des classes prépas
Si vous utilisez cet ouvrage dans le cadre du bac STI2D (Sciences et Technologies de l’Industrie et du Développement Durable) qui a introduit depuis 2011 la notation SysML™ au programme ou encore dans le cadre des classes préparatoires aux écoles d’ingénieur qui devraient l’adopter bientôt, nous donnons ici des conseils sur l’utilisation de ce cours [3].
L’objectif dans ces niveaux n’est pas de former des spécialistes de SysML™ mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.
|
|
À l’heure où nous écrivons ces lignes, il est en effet prévu de l’enseigner en classe prépa dès la rentrée 2013. |
3.1. Utilisation pratique en STI2D
Cet ouvrage est tout à fait utilisable dans le cadre des ces cours. Pour STI2D, seul un sous-ensemble des diagrammes de SysML™ a été retenu. Les élèves et les enseignants du bac STI2D pourront trouver dans ce document des éléments utiles sur ces diagrammes :
-
diagramme des exigences (cf. Les exigences)
-
diagramme des cas d’utilisation (cf. Use Case Diagrams)
-
diagramme de séquences (cf. Sequence Diagrams)
-
diagramme d'états (cf. Diagramme d'états)
-
diagramme de définition de blocs (cf. Block Definition Diagrams)
-
diagramme de blocs internes (cf. Internal Block Diagrams)
Ces 6 diagrammes sont tous traités dans cet ouvrage à un niveau qui devrait correspondre à l’utilisation qui en est faite en STI2D.
Ils servent trois objectifs principaux inscrits au programme et dont les élèves pourront également trouver des éléments de réflexion :
-
Modélisation des exigences (cf. Les exigences)
-
Modélisation structurelle (cf. L’architecture du système)
-
Modélisation comportementale (cf. Le comportement du système)
|
|
Un blog récent recense les supports en liens avec STI2D : http://www.scoop.it/t/formation-sysml-sti2d. |
3.2. Classe préparatoire et UPSTI
L’Union des Professeurs de Sciences et Techniques Industrielles (UPSTI) prépare à l’heure où nous écrivons ces lignes un document de cadrage en terme de méthodologie et de démarche. Nous n’insisterons donc pas sur ces aspects, mais donnerons quelques pistes dans le chapitre commun sur les conseils d’enseignement (cf. Pédagogie).
Notons que dans ce cadre-là, les 9 diagrammes sont utilisables même si pour l’instant les diagrammes paramétriques et de paquetages sont un peu mis en retrait.
3.3. Pour aller plus loin
Les questions et exercices de fin de chapitres de la partie notation seront peut-être d’un niveau plus avancé pour servir véritablement d’exercices, mais pourront amener à une réflexion encadrée par l’enseignant.
4. Un exemple fil rouge
L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est celui d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).
Il existe un certain nombre d’autres exemple complets :
-
Le radio-réveil de Pascal Roques [Roques2010], un exemple simpliste mais didactique qui a le mérite d'être déjà connu des modeleurs UML™ qui ont lu ses livres.
-
Le distilleur de [FMS], un exemple très complet et lui aussi très connu car beaucoup utilisé dans les tutoriels issus de l’OMG™.
-
Le pacemaker de [SeeBook2012][4], un exemple très récent et dont l’avantage est d'être traité selon plusieurs approches différentes et complémentaires (SysML™, AADL et MARTE).
Les exemples complets ont le mérite de donner une vue d’ensemble des liens qui peuvent exister entre les différents diagrammes. On peut y voir comment ces diagrammes sont complémentaires les uns des autres. Ils sont en général plus réalistes que les diagrammes utilisés pour illustrer tel ou tel concept de la notation.
4.1. Enoncé
|
|
Cette étude de cas est tirée de Kienzle2010 |
Le système CMS (crash management system) est un système distribué de gestion d’accidents qui est responsable de la coordination et de la communication entre un coordinateur présent dans une caserne de pompiers (appelé FSC pour Fire Station Coordinator) et un autre présent dans un poste de police (appelé PSC pour Police Station Coordinator) afin de gérer une crise dans un délai raisonnable.
La communication interne entre les membres de la police (y compris le PSC) est en dehors du domaine qui nous intéresse ici (la gestion de crise). La même hypothèse s’applique aux communications internes ou avec des acteurs externes côté pompiers (y compris le FSC). Les informations concernant la crise ainsi que tout ce qui a trait aux tâches des coordinateurs sont mises à jour et maintenues pendant et après la crise.
Il n’existe pas de base de données centrale; caserne de pompiers et police ayant leur base de données respectives distinctes et seulement accessible aux autre à travers le système CMS. Chaque processus de coordination est donc en charge de l’ajout et la mise à jour des informations dans sa base de données respective.
CMS commence à fonctionner au moment où une crise donnée a été détectée et déclarée à la fois à la caserne de pompiers et au poste de police.
Toutes les caractéristiques des différents acteurs sont détaillées ci-dessous.
4.1.1. Coordinateur des pompiers (FSC)
Un FSC maintient le contrôle sur une situation de crise en communiquant avec le coordinateur du poste de police (PSC) ainsi que les pompiers.
Pour atteindre ses objectifs, les responsabilités d’un FSC sont les suivantes :
-
de déterminer où, quand et combien de camions de pompiers à envoyer,
-
de communiquer avec le PSC pour se présenter,
-
de garder le PSC informé en ce qui concerne la crise,
-
de proposer une stratégie pour traiter la crise,
-
parvenir à un accord avec le PSC sur la façon de procéder,
-
de recevoir des mises à jour concernant la crise côté pompiers, et
-
de rassembler et de diffuser des informations actualisées aux pompiers.
4.1.2. Pompiers
Un pompier agit sur ordres reçus du FSC et des fait des rapports au FSC. Par ailleurs, un pompier communique avec d’autres pompiers, des victimes et des témoins.
Les responsabilités d’un pompier sont les suivantes :
-
recevoir des demandes pour aller/revenir sur les lieux de la crise,
-
signaler sa position au FSC,
-
signaler les conditions de la crise au FSC et à tous les pompiers, et
-
communiquer avec les victimes et les témoins.
4.1.3. Coordinateur du poste de police (PSC)
Pour atteindre ses objectifs, un PSC effectue les mêmes activités que le FSC.
4.1.4. Agents de police
Les agents de police agissent sur ordres reçus du PSC. En outre, un agent de police communique avec d’autres policiers, des victimes et des témoins. Pour atteindre ses objectifs, un agent de police exerce les mêmes activités qu’un pompier en termes de communication avec son coordinateur.
4.1.5. Victimes (de la crise)
Une victime a été touchée par la crise et peut communiquer avec les policiers et les pompiers. Les responsabilités d’une victime sont :
-
de fournir des informations liées à la crise
-
de suivre les instructions de pompiers et de policiers.
4.1.6. Témoins (de la crise)
Un témoin a observé la crise et communique avec les policiers et les pompiers. Les responsabilités d’un témoin sont les suivantes :
-
de fournir des informations aux pompiers et les policiers, et
-
de suivre les instructions de pompiers et de policiers.
4.1.7. Informations complémentaires
Pour enrichir vos modèles, on pourra incorporer certains des besoins non-fonctionnels décrits en annexe (cf. Annexes).
Partie 2 : Ingénierie système
1. Introduction
La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
Cette matrice permet de situer les différents éléments qui seront vus dans ce cours dans un cadre utile pour comparer ces éléments les uns aux autres. Je vous conseille de vous faire votre propre matrice. L’essentiel est de toujours bien se représenter les différents éléments qu’on aborde dans une carte mentale précise. Cela permet une meilleure mémorisation.
1.1. Points de vue
Dans un axe horizontal, j’ai différencié quatre grands points de vue :
- Requirements
-
Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de Les exigences) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML™.
- Structure
-
La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML™ qui pose le moins de problème aux débutants.
- Comportement
-
Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.
- Transverse
-
Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.
Ces différents points de vue ne doivent pas être confondus avec les différentes phases de développement (cf. paragraphe suivant). Ils sont plutôt à rapprocher de la notion de préoccupation. C’est ainsi que j’ai choisi de distinguer trois points de vue qui se retrouvent souvent en modélisation : le point de vue des exigences qui permet de se focaliser sur les besoins des clients ; le point de vue structurel qui permet de se focaliser sur les différents composants du système ; et le point de vue comportemental qui permet de se focaliser sur le comportement du système. Ces trois points de vue n'étant pas indépendants les uns des autres, j’ai intégré un quatrième point de vue transversal.
1.2. Phase de développement
Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :
- Organisation
-
Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)
- Analyse
-
Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.
- Conception
-
Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)
- Implémentation
-
Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).
Il s’agit ici classiquement des grandes étapes de développement d’un système. On pourrait être surpris par l'étape que j’ai appelé « organisation ». C’est une étape que je considère importante, particulièrement pour l’enseignement. Avant toute activité de modélisation ou de même de développement, il convient en effet de s’organiser en termes de choix d’outils, choix d’environnement, etc. Cette étape est souvent négligée par les étudiants. C’est pour cela que j’ai décidé de faire figurer cette étape de manière explicite. Bien sûr dans une organisation existante cette étape sera contrainte par les habitudes « maison ».
2. Différence avec l’ingénierie logicielle
Enseignant en informatique, je me retrouve souvent à enseigner SysML™ à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".
2.1. Une ingénierie plus ancienne
Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.
2.2. Des systèmes plus complexes
On parle de système complexe lorsque l’on a affaire à un ensemble d'éléments humains et matériels en relation avec :
-
de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)
-
intégrés pour fournir des services (finalité du système) en fonction de leur environnement
-
interagissant entre eux et avec leur environnement
On parle aussi de Système de systèmes quand un système :
-
doit gérer les interactions entre ses parties (ou composantes)
-
assure un comportement prévu à l’avance
-
gère les comportements (de l’environnement) inatendus
2.3. Différents types d’analyse
Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible (cf. IS : problème).
Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :
Le but de ces analyses est d’arriver à combler le gap entre le système à développer et ses spécifications (cf. IS : solution).
3. Normes et standards
Il existe un grand nombre de standards en Ingénierie Système. Cette section aurait pu faire une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, NASA, INCOSE, AFIS, …). Néanmoins, les aspects normalisation et standardisation sortent du cadre de ce document. Pour plus de détails sur ces aspects, je renvoie le lecteur à un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.
Ce qu’il faut retenir tout de même, c’est que l’Ingénierie Système génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels. De plus en plus de grands comptes comme Airbus, Thalès, cherchent à utiliser des modèles pour remplacer à terme la documentation. L’idée est de générer cette documentation à partir des modèles et non l’inverse comme c’est plutôt le cas aujourd’hui.
Enfin je noterai concernant cette section qu’il est bien sûr important, avant tout travail de modélisation, de bien se renseigner sur les différentes procédures en vigueur dans votre entreprise. Il convient de respecter bien évidemment les normes et standards qui contraignent votre activité.
4. Des documents aux modèles
Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. Pourquoi une nouvelle notation).
En Ingénierie Système il arrive parfois que les personnes responsables des différents aspects de la modélisation soient complètement déconnectées. Par exemple une équipe complète d’ingénieurs spécialisés dans les exigences va les traiter puis une équipe spécialisée dans les aspects architecture et composants va définir la partie physique du système. Une autre équipe spécialisée dans les comportements va modéliser le comportement du système. L’utilisation d’un langage commun, comme SysML™, pour toutes ces phases est une façon d’assurer la cohérence et la complémentarité des différents modèles.
5. Les exigences
L’ingénierie des exigences est d’une importance capitale en Ingénierie Système. En général les exigences sont exprimées par des ingénieurs dédiés à cette activité. La complexité des systèmes modernes (embarqués, communicants, critiques, …).
|
|
Besoins, exigences : question de vocabulaire
La difficulté de l’emploi massif de l’anglais en Ingénierie Système fait qu’il existe souvent une confusion entre les termes anglais et leurs traduction française. Nous précisons donc ici notre utilisation des termes :
|
Il est important pour une exigence qu’elle ne soit pas ambiguë (contrairement au terme en dans la consigne exprimée par la maman dans l’illustration ci-dessous : "Ramène moi 1 bouteille de lait. S’il y a des oeufs, ramène m’en 6.").
6. L’architecture du système
Liens avec AADL, …
7. Le comportement du système
Liens avec la V&V
8. Méthodes et démarches
Everything should be made as simple as possible, but not simpler.
SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. Considérations méthodologiques pour la présentation de quelques méthodes bien identifiées) :
Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau bloc lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.
Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. La carte de base).
N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.
Partie 3 : La notation SysML
1. Pourquoi une nouvelle notation
A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
— Bertrand Russell
Il existe une notation qui se veut "unifiée" pour les modèles : UML™. Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :
-
UML 1.x était complètement inadaptée :
-
Principalement pour les systèmes d’information
-
Peu de liens entre les diagrammes
-
Peu de liens entre les modèles et les exigences
-
-
UML 2.x n’est pas beaucoup mieux si ce n’est :
-
Implication des ingénieurs systèmes pour sa définition
-
Introduction du diagramme de structure composite
-
En conclusion UML™ est une bonne base :
-
Standard De facto en génie logiciel
-
Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)
-
Stable et extensible (grâce notamment au mécanisme de profile)
-
Beaucoup d’outils disponibles
Mais…
-
Manque de certains concepts clés d’Ingénierie Système
-
Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de
classeou d'héritagepar exemple) -
Trop de diagrammes (13 sortes)
2. Introduction à SysML
2.1. Fiche d’identité
Voici à quoi pourrait ressembler la fiche d’identité de SysML™ :
2.2. Différence avec UML
La figure suivante, tirée de la spécification, résume bien les liens entre SysML™ et UML™, à savoir que SysML™ reprend une partie seulement des concepts d’http://www.uml.org/[UML™] (appelée UML4SysML) en y ajoutant des concepts nouveaux.
2.3. Qui est "derrière"?
- Industrie
-
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
- Vendeurs d’outils
-
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …
- Autres organisations
-
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …
|
|
La liste complète des membres de l’OMG™ est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl |
2.4. Organisation des différents diagrammes
SysML™ propose de couvrir la modélisation d’un système en 9 diagrammes. Ces diagrammes couvrent les aspects structurels et comportementaux du système ainsi que les exigences. Le diagramme suivant présente cette organisation en faisant au passage le lien avec ceux d’http://www.uml.org/[UML™] :
Le nom de ces diagrammes revenant souvent dans ce document, nous utiliserons souvent leur version abrégée
(uc pour "diagramme des UC" par exemple). Ces abréviations, sont définies dans la spécification (cf. note suivante).
|
|
Définition : Types de diagrammes (OMG SysML v1.3, p. 170)
SysML diagram kinds should have the following names or (abbreviations) as part of the heading… |
2.5. Différence entre modèle et dessin
SysML™ n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML™. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.
C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML™ [5], mais d’utiliser des outils dédiés (cf. Outils SysML). Ils respectent en général la norme OMG SysML v1.3 (bien qu’il faille se méfier).
|
|
Notez que la norme permet de faire des adaptations graphiques (cf. la discussion http://www.realtimeatwork.com/2011/08/is-sysml-too-abstract/). |
Un des intérêts de la modélisation est de faciliter la communication, notamment au travers des diagrammes et leur aspect graphique et synthétique. Un dessin est donc un plus par rapport à du texte. Néanmoins, il ne faut pas se contenter d’un simple dessin pour au moins deux raisons importantes :
-
un dessin n’est pas assez formel (comment être sûr d’avoir correctement utilisé tel ou tel symbole, cf. les deux exemples ci-dessous) ;
-
il est impossible d’assurer la cohérence globale des modèles dans le cas d’un dessin.
Un modèle est une sorte de base de donnée qui regroupe des éléments issues de différents points de vue (saisis le plus souvent au travers de diagrammes). Un diagramme est une vue partielle du modèle (donc incomplète). Le modèle est la vraie plus value car il va permettre de détecter les incohérences sur les exigences, les problèmes de complétude, lancer des analyses, faire des transformations vers d’autres langages ou formats, etc. Par exemple dans un outil de modélisation il y a une grande différence entre supprimer un élément d’un diagramme (on parlera alors de "masquer" un élément d’un diagramme) et supprimer un élément de modèle (ce qui aura pour effet de supprimer cet élément de tous les diagrammes où il était présent).
Voici deux exemples de non respect de la notation qui illustre le type d’erreur que l’on trouve souvent dans les modèles qui circulent sur Internet ou même parfois dans certains livres.
2.5.1. Diagramme de bloc
Par exemple dans ce diagramme les blocs ne respectent pas la syntaxe graphique de SysML™ :
|
|
Erreur : mauvais symboles graphiques pour les blocs
|
Pour rappel, la notation jmb : Personne permet de représenter un objet (une instance d’une classe ou d’un bloc).
C’est donc une notation utilisée par exemple dans les participants d’un diagramme de séquence ou encore les parties
d’un diagramme interne de bloc.
Donc dans le diagramme ci-dessus, l’acteur est correct (on peut mettre des acteurs dans un bdd, cf. OMG SysML v1.3 p.32), par contre
les objets Block : … est une erreur de notation.
|
|
Solution : utiliser un outil (ici BOUML)
|
|
|
Attention, il est tout à fait possible de représenter des instances dans un bdd (cf. OMG SysML v1.3 p.34), même si c’est très peu courant. |
2.5.2. Diagramme de séquence
|
|
Erreur : pb avec les participants et la boucle
|
Plusieurs problèmes de non respect de la notation :
-
il manque le rectangle aux participants
-
les participants semblent être des blocs et non des instances
-
la boucle devrait avoir une condition (même "toujours" pour une boucle infinie)
|
|
Le dernier problème est plus une convention qu’une véritable erreur. Cf. Conventions et recommandations. |
2.6. Outils SysML
Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :
Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.
Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.
|
|
Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation. |
Dans le cadre de notre exemple fil rouge, nous utilisons l’outil TOPCASED.
2.7. Cadre pour les diagrammes
Abordons quelques principes généraux de SysML™, c’est à dire des éléments indépendant d’un diagramme en particulier :
-
Chaque diagramme SysML™ décrit un élément précis (nommé) de modélisation
-
Chaque diagramme SysML™ doit être représenté à l’intérieur d’un cadre (Diagram Frame)
-
L’entête du cadre, appelé aussi cartouche, indique les informations sur le diagramme : le type de diagramme (
req,act,bdd,ibd,stm, etc.); le type d'élément (package, block, activity, etc.); le nom de l'élément et le nom du diagramme ou de la vue.
Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un
package, nommé "Context".
|
|
Convention : Utilisation systématique des cartouches
Tout diagramme proposé à un étudiant pour décrire un système devrait posséder un entête précis. |
Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la La carte de base) :
| Requirements, cf. Les exigences | Structure, cf. L’architecture du système | Comportement, cf. Le comportement du système | Transverse, cf. Les aspects transversaux | |
|---|---|---|---|---|
Organisation |
|
|
|
|
Analyse, Conception, Implémentation [6] |
|
|
|
|
2.8. Organisation
2.8.1. Fondements
On abordera :
-
Le Package Diagram
-
Les différent types de packages
-
Les organisations possibles
-
La notion de Namespaces
-
Les Dependencies
2.8.2. Le Package Diagram
Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.
Ce diagramme est identique à celui d’http://www.uml.org/[UML™], et le concept de paquetage (package) est classique pour les développeurs (java notamment). Il permet d’organiser les modèles en créant un espace de nommage (cf La notion de Namespaces).
Les modèles peuvent être organisés selon toutes sortes de considération (cf. Les organisations possibles) :
-
hiérarchie "système" (e.g., entreprise, système, composant)
-
types de diagrammes (e.g., besoins, structure, comportements)
-
par points de vue
-
etc.
2.8.3. Les différent types de packages
Il existe plusieurs types de package :
- models
-
un package "top-level" dans une hiérarchie de packages
- packages
-
le type le plus classique : un ensemble d'éléments de modèles
- model librairies
-
un package prévu pour être réutilisé (importé) par d’autres éléments
- views
-
un package spécial pour représenter les points de vue
|
|
Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation.
Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une
vue (un packetage particulier, stéréotypé |
2.8.4. Les organisations possibles
Les modèles peuvent être organisés selon toutes sortes de considération :
-
par hiérarchie "système" (e.g., entreprise, système, composant, …)
-
par types de diagrammes (e.g., besoins, structure, comportements, …)
-
par cycle de vie (e.g., analyse, conception, …)
-
par équipes (e.g., architectes, [IPT], …)
-
par points de vue (e.g., sécurité, performance, …)
-
etc.
|
|
L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut. |
2.8.5. La notion de Namespaces
Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.
|
|
Définition : Namespace (OMG SysML v1.3, p. 23)
The package defines a namespace for the packageable elements. |
Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name),
c’est à dire le nom de l'élément préfixé par son (ou ses) package(s)
(e.g., Structure::Products::Clock).
|
|
Dans les outils SysML™, il faut souvent demander explicitement à voir les noms complets (Qualified names) des éléments (la plupart du temps dans les options graphiques). |
2.8.6. Les dépendances
Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :
- Dependency
-
une dépendance "générale", non précisée,
représentée par une simple flèche pointillée-----> - Use
-
l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype<<use>> - Refine
-
l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype<<refine>> - Realization
-
l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype<<realize>> - Allocation
-
l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un
blockla plupart du temps),
représentée par le stéréotype<<allocate>>
2.8.7. En résumé
SysML™ propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’http://www.uml.org/[UML™]. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|
|
|
… |
2.8.8. Questions de révision
-
Quels sont les 5 types de dépendances entre packageable elements ?
-
À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?
2.9. Les exigences
2.9.1. Fondements
On abordera :
-
L’organization des Requirements
-
Les Requirements properties
-
Les Requirements links
-
Les Requirements Diagrams
-
Les considérations sur la traçabilité
-
Annotations des Requirements
-
Les Use Case Diagrams
|
|
L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de {lafis} ([REQ2012]). |
2.9.2. L’organisation des Requirements
Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML™ permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.
Représentation de base
Un Requirement en SysML™ n’est qu’un bloc particulier.
|
|
Définition : Requirements (OMG SysML v1.3, p. 139)
A requirement specifies a capability or condition that must (or should) be satisfied… A requirement is defined as a stereotype of UML Class… |
Différents types d’organisation
L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML™ à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.
Plusieurs types d’organisations sont possibles :
-
Par niveau d’abstraction
-
Besoins généraux (en lien avec les use cases par exemple)
-
Besoins techniques (en lien avec les éléments de conception)
-
-
Par point de vue
-
Besoins principaux (en lien avec les use cases)
-
Besoins spécifiques :
-
Fonctionnels
-
Marketing
-
Environnementaux
-
Business
-
…
-
-
-
etc.
Tableaux de Requirements
Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.
|
|
Définition : Requirements Table (OMG SysML v1.3, p. 145)
The tabular format is used to represent the requirements, their properties and relationships… |
La plupart des outils modernes permettent le passage entre outils classiques de gestion des exigences (comme DOORS™) et outils de modélisation SysML™ (comme Modelio, illustré ci-dessous).
2.9.3. Les Requirements properties
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
-
priority (
high,low, …) -
source (
stakeolder,law,technical, …) -
risk (
high,low, …) -
status (
proposed,aproved, …) -
verification method (
analysis,tests, …)
2.9.4. Les Requirements links
Les principales relations entre requirement sont :
- Containment
-
Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").
- Refinement
-
Pour décrire un ajout de précision (
<<refine>>), comme par exemple une précision. - Derivation
-
Pour indiquer une différence de niveau d’abstraction (
<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes.
|
|
Lorsqu’une exigence possède plusieurs cas |
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation
(les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons
dans la partie transverse.
2.9.5. Les Requirements Diagrams
Voici un exemple de req un peu plus étoffé, tiré de http://www.uml-sysml.org/sysml (voir aussi Exemples de rationale et problem) :
2.9.6. Stéréotyper les Requirements
Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :
-
<<interfaceRequirement>>,<<physicalRequirement>>, … -
<<FunctionalRequirement>>,<<nonFunctionalRequirement>>
2.9.7. Annotations des Requirements
Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).
2.9.8. Les considérations sur la traçabilité
Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases
(en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci
sera abordé dans la partie Les aspects transversaux.
|
|
En général chaque requirement devrait être relié à au moins un use case (et vice-versa!). |
2.9.9. Les Use Case Diagrams
Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.
Ce diagramme est exactement identique à celui d’http://www.uml.org/[UML™].
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
2.9.10. En résumé
Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML™.
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|||
Analyse |
|
|
|
|
Conception |
|
|||
Implémentation |
|
En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. Exemple de démarche (SYSMOD Zigzag pattern)).
2.9.11. Questions de révision
-
Quelles sont les différences entre besoins et exigences ?
-
En quoi les cas d’utilisation sont-ils complémentaires des exigences?
-
Quelle est la différence entre un package de type model et un package de type package?
2.10. L’architecture du système
2.10.1. Fondements
On abordera :
-
l’organisation du système et des modèles
-
les Block Definition Diagrams
-
les Internal Block Diagrams
-
les Parametric Diagrams (pour les contraintes physiques)
-
les Sequence Diagrams (diagramme de séquence système)
2.10.2. Organisation du système et des modèles
En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation (cf. Le Package Diagram).
Pour l’organisation du système, on trouve le plus souvent :
-
un diagramme décrivant le contexte (le système dans son environnement), décrit dans un block definition diagram (cf. bdd du système dans son environnement)
-
un diagramme décrivant les éléments internes principaux du système, décrit dans un internal block diagram
2.10.3. Block Definition Diagrams
Principes de base
Un bdd peut représenter :
-
un package
-
un bloc
-
un bloc de contrainte (constraint block)
Un diagramme de bloc décrit les relations entre les blocs (compositions, généralisations, …). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML™.
Un bloc est constitué d’un certain nombre de compartiments (Compartments) :
- Properties
-
Equivalent UML™ des propriétés (e.g., attributs).
- Operations
-
Les méthodes supportées par les instances du bloc.
- Constraints
-
Les contraintes (cf. Exemple de définition de contraintes)
- Allocations
-
Les allocations (cf. Les aspects transversaux)
- Requirements
-
Les exigences liées à ce bloc.
- User defined
-
On peut définir ses propres compartiments.
Propriétés
On peut différencier 4 types de propriétés d’un bloc :
- value properties
-
Des caractéristiques (quantifiables), aussi appelées simplement values
- parts
-
Les éléments qui composent le bloc (cf. Internal Block Diagrams)
- references
-
Les éléments auquel le bloc a accès (via des associations ou des agrégations)
- constraint properties
-
Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. Parametric Diagrams).
|
|
Les values sont ce qui se rapproche le plus des attributs de classes UML. |
Value Types
Pour associer un type aux valeurs, SysML™ propose de définir des Value Types.
Associations entre blocs
Il existe deux types de relations entre blocs :
-
l’association (y compris l’agrégation et la composition)
-
la généralisation/spécialisation
Ces deux types de relations, bien connues en UML™, permettent de matérialiser les liens qui existent entre les éléments du système. Avant d’aborder les associations, il est important de différencier la description d'éléments structurels sous la forme d’un bloc (au travers d’un bdd par exemple) et ces éléments pris individuellement. Ces derniers sont des instances individuelles du même bloc. Cette notion, très présente dans les approches orientées objets est souvent plus ardue à appréhender pour les ingénieurs systèmes. Il faut bien comprendre que la modélisation d’un bloc consiste à représenter l’ensemble des éléments qui caractérisent tout une série d’objets (des moteurs, des pompes, des données, etc.). Il serait fastidieux de les représenter tous (individuellement), et c’est donc leur "signature" que l’on représente. C’est pour cela qu’un bloc n’est pas un élément physique, mais simplement sa représentation, tandis qu’une instance de ce bloc représentera elle cet élément physique. C’est le cas notamment des participants d’un diagramme de séquence ou encore des parties d’un composé, qui sont des instances et non des blocs.
Association
Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.
Une association possède plusieurs propriétés :
- Dimension d’une association
-
Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)
|
|
Exemple d’association binaire
Soient les bloc |
- Nom d’une association
-
Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :-
un verbe à l’infinitif (e.g.,
Fournir) -
un verbe conjugué avec un sens de lecture :
Fournit >ou< Est fourni par -
un rôle (placé à une extrémité de l’association)
-
- Cardinalité
-
Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple
(M..N).
|
|
Attention, dans une cardinalité |
Vers le code : que signifie vraiment une association?
En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.
Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple
que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante)
de type tableau (ou liste, ou …) de Fournisseurs.
Ce qui peut donner en java :
public class Produits
{
//Produits Attributes
private String idPro;
private String designation;
private float poids;
//Produits Associations
private List<Fournisseurs> fournisseurs;
...
En terme d’ingénierie système, on utilisera plutôt des associations spécifiques (l’agrégation et la composition).
BEn terme d’Ingénierie Système, une composition indique que l'élément est une partie intégrante (on parle de part) du tout (un composant, comme le moteur d’une voiture par exemple) tandis q’une agrégation indique que l'élément est une partie "externe" (on parle de reference) comme la batterie d’un portable.
|
|
Un moyen simple en terme logiciel de déterminer si une association
|
Généralisation/Spécialisation
Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les points communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes et que l’on créé alors des blocs spécifiques, on parle alors de spécialisation.
On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.
2.10.4. Internal Block Diagrams
Un ibd décrit la structure interne d’un bloc sous forme de :
- parts
-
Les parties qui constituent le système (ses sous-systèmes)
- ports
-
Elément d’interaction avec un bloc
- connecteurs
-
Liens entre ports
Parts
Les parties sont représentés par les éléments au bout d’une composition dans un bdd.
Elles sont créés à la création du bloc qui les contient et sont détruites avec lui s’il
est détruit (dépendance de vie).
|
|
Il ne s’agit pas de redessiner le BDD. Les parts sont des instances et non des classes (au sens objet). |
On représente les parts comme des bloc en traits pleins et les references comme des blocs en trait pointillés.
Ports (SysML 1.2)
|
|
La dernière version de la spécification OMG SysML v1.3 préconise l’abandon des ports tels que définis dans la version 1.2. Nous présentons les nouvelles notions dans la section qui suit. Néanmoins, de par l’importance des exemples qui utilisent les notions habituelles de ports, et vu que tous les outils ne supportent pas encore les nouveaux ports, nous indiquons ici leur définition et recommandons pour l’instant de les utiliser. |
Les ports :
-
préservent l’encapsulation du bloc
-
matérialise le fait que les interactions avec l’extérieur (via un port) sont transmise à une partie (via un connecteur)
-
les ports connectés doivent correspondre (kind, type, direction, etc.)
|
|
Les ports définissent les points d’interaction offerts ( |
|
|
Définition : Ports (OMG SysML v1.3, p. 57)
Ports are points at which external entities can connect to and interact with a block in different or more limited ways than connecting directly to the block itself. |
Les ports peuvent être de nature classique (comme en UML™) et représenter la fourniture ou le besoin de services. On parle alors de *standard flows*.
Ils peuvent aussi être de nature "flux physique", on parle de *flow ports*.
Les Flux peuvent être :
-
atomiques (un seul flux),
-
composites (agrégation de flux de natures différentes).
|
|
Un flow port atomique ne spécifie qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Il peut être typé par un bloc ou un Value Type représentant le type d’élément pouvant circuler en entrée ou en sortie du port. |
Ports (SysML 1.3)
La nouvelle spécification OMG SysML v1.3 introduit les concepts de:
- proxy port
-
Ils doivent remplacer les ports 1.2 (ports de flots et ports standards) en en reprenant les caractéristiques et en ajoutant la possibilité d’imbrication et de spécification renforcée.
- full port
-
En fait il s’agit du même concept qu’une partie qui serait exposée à l’extérieur.
|
|
Pour une discussion sur les différences entre les deux ports : http://model-based-systems-engineering.com/2013/09/23/sysml-full-ports-versus-proxy-ports/ |
2.10.5. Parametric Diagrams
Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML™ utilise trois concepts clefs :
-
Constraints (un type de bloc)
-
Parametric diagram (un type d'
ibd) -
Value binding
Contraintes
C’est un bloc particulier :
-
avec un stéréotype
≪constraint≫(au lieu de bloc) -
des paramètres en guise d’attributs
-
des relations liant (contraignant) ces paramètres
|
|
Définition : ConstraintBlock (OMG SysML v1.3, p. 86)
A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. |
Diagramme paramétrique
C’est une forme particulière de Internal Block Definition
Value Binding
Une fois les contraintes exprimées, il faut lier les paramètres (formels) à des valeurs (paramètre réel). C’est l’objet des Value Binding.
Pour assigner des valeurs spécifiques, on utilise des Block Configurations;
2.10.6. Diagrammes de séquence système
Les diagrammes de séquence système (DSS) sont des Sequence Diagrams UML™ classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs généralement).
Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les Sequence Diagrams).
2.10.7. En résumé
En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à l'ibd correspondant).
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|||
Analyse |
|
|||
Conception |
|
|||
Implémentation |
|
2.10.8. Questions de révision
-
Quelles sont les différences entre une association dirigée (
→), une composition (losange noir) et l’agrégation (losange blanc) ? -
Puisqu’un
bddme donne souvent la liste des sous-systèmes (liens de composition), pourquoi ai-je besoin d’unibd?
2.11. Le comportement du système
2.11.1. Fondements
On abordera :
-
les Use Case Diagrams
-
les Sequence Diagrams
-
les State Machines
-
les Activity Diagrams
2.11.2. Use Case Diagrams
Les éléments de base :
- Acteurs
-
Les principaux éléments extérieurs au système considéré, et participant qui participent (on parle parfois d’acteurs principaux). Ils ont souvent un rôle. ou qui bénéficient (on parle alors d’acteurs secondaires) du système.
- Cas d’utilisation
-
représente un ensemble d’actions réalisées par le système intéressant pour au moins un acteur
- Association
-
participation d’un acteur à un cas d’utilisation.
- Sujet
-
le domaine étudié (qui peut être une partie seulement de tout le système, pas forcément modélisé dans son ensemble)
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
2.11.3. Le Diagramme des Cas d’Utilisation
Le Diagramme des Cas d’Utilisation est un diagramme UML™ permettant de représenter :
-
les UC (Use Case ou Cas d’Utilisation)
-
les acteurs (principaux et secondaires)
-
les relations
-
entre acteurs et Use Case
-
entre Use Cases
-
Cas d’Utilisation (Use Case)
Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.
Exemple de cas d’utilisation (UML)
Retrait par carte bancaire
- Scénario principal
-
L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.
- Scénario alternatif n°1
-
Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.
- Exemple de codification de l’UC
-
UC01 ou RetraitCB (pour Retrait par carte bleue)
Précisions
Un cas d’utilisation peut être précisé par :
-
une description textuelle
-
un ou des diagrammes UML™ (séquence, activité)
|
|
Dans les outils, cette "précision" se manifeste par le fait que l’on "attache"
généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un Use Case → nouveau |
Acteur
Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.
On peut trouver plusieurs types d’acteurs :
-
extérieurs au système (cf.
actorNotation dans le diagramme d’UC)-
les acteurs principaux
-
les acteurs secondaires
-
-
exemples de types d’acteurs prédéfinis dans UML :
-
<<utility>> -
<<process>> -
<<thread>>
-
|
|
On peut utiliser des liens de généralisation/spécialisation entre acteurs pour représenter les possibilités pour le spécialisé d’avoir les mêmes prérogatives (notamment en terme d’utilisation du système) que le généralisé. |
Relations entre acteurs et Use Case
En général, une simple association relie acteurs et Use Case. On peut également orienter ces associations en plaçant une direction (flèche vide) au bout de l’association.
Relations entre Use Case
Après avoir lister les cas d’utilisation, il est utile de les organiser et de montrer les relations entre eux. Plusieurs relations sont possibles :
- Extension (
<<extend>>) -
Indique que le Use Case source est éventuellement exécutée en complément du Use Case destination (cas particulier, erreur…). Le point précis où l’extension peut se produire est appelé extension point (surtout utile quand il existe plusieurs extensions pour un même cas)
- Inclusion (
<<include>>) -
Indique que le Use Case est inclus obligatoirement dans un autre Use Case (notion de sous-fonction par exemple)
- Généralisation
-
Relation entre un Use Case général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute (différents modes d’utilisation d’un système par exemple, ou encore différents acteurs impliqués)
|
|
On n’utilise généralement |
Pour construire un UC (de manière générale)
-
identifier les acteurs
-
identifier les cas d’utilisation
-
structurer en packages
-
finaliser les diagrammes de cas d’utilisation (ajouter les relations)
|
|
Certains méthodologistes (comme Tim Weilkiens) préconisent de ne pas utiliser les acteurs et les cas d’utilisation (cf. son blog) |
2.11.4. Sequence Diagrams
Généralités
Il permet de :
-
modéliser les interactions entre blocs
-
séquencer ces interactions dans le temps
-
représenter les échanges de messages
-
spécifier les scénarios des cas d'études
Les éléments qui composent ce diagramme sont :
- Participants
-
les éléments en interaction (des blocs généralement)
- Lignes de vie
-
des lignes verticales qui permettent d’indiquer un départ ou une arrivée d’interaction
- Barres d’activation
-
pour matérialiser quand l'élément est actif
- Messages
-
ce qui "circule" d’un élément à l’autre (signal, appel de méthode, …)
|
|
Les participants (et leur ligne de vie) représentent des instances de blocs (souvent "anonymes"). |
Notions avancées
On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :
-
loop(boucle) -
alt(alternative) -
opt(optionel) -
par(parallèle) -
region(région critique - un seul thread à la fois)
Exemple de conceptions
Le diagramme de séquences est un diagramme utile pour montrer les "responsabilités" de certains objets par rapport aux autres. Dans un code logiciel, on peut y déceler plus facilement que tel objet est plus chargé que d’autres. Les deux diagrammes suivants (tirés de [Fowler2004]) montrent deux conceptions différentes possibles pour l’implémentation d’une même fonctionnalité. On mesure visuellement assez bien la différence entre la version "centralisée" (Conception "centralisée") et la version "objet" (Conception "objet").
|
|
On utilise le diagramme de séquence pour représenter des algorithmes et des séquencements temporels. Lorsque le comportement se rapproche plus d’un flot, on utilise le diagramme d’activité (cf. section sur le Diagrammes d’activité). |
Lien entre UC, DSS et DS
La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.
On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.
Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.
2.11.5. Diagramme d'états
SysML™ a repris le concept, déjà connu en UML™, de machine à états (State Machines). Ce diagramme représente les différents états possibles d’un bloc particulier, et comment ce bloc réagit à des événements en fonction de son état courant (en passant éventuellement dans un nouvel état). Cette réaction (nommée transition) possède un événement déclencheur, une condition (garde), un effet et un état cible.
Le diagramme d’états comprend également deux pseudo-états :
-
l’état initial du diagramme d’états correspond à la création d’une instance ;
-
l’état final du diagramme d’états correspond à la destruction de l’instance.
Lorsqu’un état nécessite lui-même plus de détails, on créé un état composite (aussi appelé super-état) qui est lui-même une machine à état. On peut ainsi factoriser des transitions déclenchées par le même événement (et amenant vers le même état cible), tout en spécifiant des transitions particulières entre les sous-états. Il est également possible d’attacher un diagramme d'état (composite) à un état pour garder une représentation hiérarchique.
Un diagramme d'état peut représenter des régions concurrentes (dont les activités peuvent évoluer en parallèle), graphiquement représentées par des zones séparées par des traits pointillés. Chaque région contient ses propres états et transitions.
Il existe encore d’autres concepts avancés que nous ne présenterons pas dans cette introduction car ils sont beaucoup moins utilisés (entry, exit, transition interne, etc.).
2.11.6. Diagrammes d’activité
Les diagrammes d’activité (Activity Diagrams) est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé pour raffiner en général un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé ou transformé au cours de l’exécution de cette activité.
Les éléments de base du diagramme d’activité sont :
-
les actions,
-
les flots de contrôle entre actions,
-
les décisions (branchements conditionnels),
-
un début et une ou plusieurs fins possibles.
2.11.7. Actions
Les actions sont les unités fondamentales pour spécifier les comportements en SysML™. Une action représente un traitement ou une transformation. Les actions sont contenues dans les activités, qui leur servent alors de contexte.
2.11.8. Flots
Un flot de contrôle permet le contrôle de l’exécution des noeuds d’activités. Les flots de contrôle sont des flèches reliant deux noeuds (actions, décisions, etc.).
Le diagramme d’activité permet également d’utiliser des flots d’objets (reliant une action et un objet consommé ou produit). Les object flow, associés aux broches d’entrée/sortie (input/output pin) permettent alors de décrire les transformations sur les objets manipulés.
Pour permettre la modélisation des flots continus, SysML™ ajoute à UML™ la possibilité de caractériser la nature du débit qui circule sur le flot : continu (par exemple, courant électrique, fluide, etc.) ou discret (par exemple, évenements, requêtes, etc.).
On utilise pour cela des stéréotypes : <<continuous>> et <<discrete>>. Par défaut, un flot est supposé discret.
|
|
Définition : FlowProperty (OMG SysML v1.3, p. 63)
A FlowProperty signifies a single flow element to/from a block. A flow property has the same notation as a Property only with a direction prefix (in | out | inout). Flow properties are listed in a compartment labeled flow properties. |
2.11.9. Décision
Une décision est un noeud de contrôle représentant un choix dynamique entre plusieurs conditions (mutuellement exclusives). Elle est représentée par un losange qui possède un arc entrant et plusieurs arcs sortants. Il existe plusieurs noeuds de contrôle (cf. Les différents contrôles de flow SysML) :
- fork
-
Un fork est un noeud de contrôle représentant un débranchement parallèle. Il est représenté par une barre (horizontale ou verticale) qui possède un arc entrant et plusieurs arcs sortants. Le fork duplique le "jeton" entrant sur chaque flot sortant. Les jetons sur les arcs sortants sont indépendants et concurrents.
- join
-
Un join est un noeud de contrôle structuré représentant une synchronisation entre actions (rendez-vous). Il est représenté par une barre (horizontale ou verticale) qui possède un arc sortant et plusieurs arcs entrants. Le join ne produit son jeton de sortie que lorsqu’un jeton est disponible sur chaque flot entrant (d’où la synchronisation).
- flow final
-
Contrairement à la fin d’activité qui est globale à l’activité, la fin de flot est locale au flot concerné et n’a pas d’effet sur l’activité englobante.
- merge
-
La fusion est l’inverse de la décision : le même symbole du losange, mais cette fois-ci avec plusieurs flots entrants et un seul sortant.
2.11.10. Réutilisation
Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction).
L’action d’appel est représentée graphiquement par une fourche à droite de la boîte d’action, ainsi que par la chaîne : nom d’action : nom d’activité. SysML™ propose encore bien d’autres concepts et notations, comme la région interruptible, la région d’expansion ou encore les flots de type stream qui sortent du cadre de ce livre d’introduction.
2.11.11. En résumé
Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. Analyses et simulation).
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|||
Analyse |
|
|||
Conception |
|
|||
Implémentation |
|
2.11.12. Questions de révision
-
Comment, pour exprimer un comportement, savoir si j’ai besoin d’un diagramme de séquence plutôt qu’un diagramme d’activité ou encore d’une machine à état ?
2.11.13. Exercices
Diagramme des cas d’utilisation
Placez dans un diagrammes des cas d’utilisation les différents acteurs et cas correspondant à l'étude de cas suivante (en indiquant les relations) :
Pour faciliter sa gestion, un entrepôt de stockage envisage de concevoir un système permettant d’allouer automatiquement un emplacement de stockage pour chaque produit du chargement des camions qui convoient le stock à entreposer. Lors de l’arrivée d’un camion, un employé doit saisir dans le système les caractéristiques de chaque article ; le système produit alors une liste où figure un emplacement pour chaque article. Lors du chargement d’un camion les caractéristiques des articles à charger dans un camion sont saisies par un employé afin d’indiquer au système de libérer les emplacements correspondant.
2.12. Les aspects transversaux
2.12.1. Fondements
On abordera ici les aspects transversaux comme :
-
la traçabilité des exigences
-
les mécanismes d’allocation
-
le diagramme paramétrique
2.12.2. Traçabilité des exigences
Nous avons vu déjà un certain nombre de mécanismes SysML™ qui permettent de tracer les exigences.
Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un bloc <<satisfy>> une exigence).
| Requirements | Structure | Comportement | |
|---|---|---|---|
Requirements |
|
||
Structure |
|
|
|
Comportement |
|
Comme indiqué dans le tableau ci-dessus, en général, le lien de raffinement est utilisé entre une exigence et un élément comportemental (état, activité, uc, etc.) tandis que l’allocation concerne principalement les éléments de structures.
XXX Mettre un exemple avec tous ces liens. XXX
2.12.3. Mécanismes d’allocation
Un mécanisme nouveau en SysML™ et important pour l’Ingénierie Système est le mécanisme d'allocation. Il permet de préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.
Il est possible d’exprimer cette allocation de plusieurs manières.
Parler du <<AllocatedTo>>, compartiments des blocs et autres annotations.
Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple.
Parler des <<allocate>>.
2.12.4. Diagramme paramétrique
C’est une forme particulière de Internal Block Definition (cf. Parametric Diagrams). On y retrouve les contraintes, déjà vues (cf. Exemple de définition de contraintes), mais cette fois-ci on a la représentation graphique des liens entre les données.
Il est regrettable que ce diagramme soit le moins utilisé (cf. Diagrammes les plus utilisés (tiré de [OMG2009])).
|
|
Certaines approchent (cf. [MeDICIS]) utilisent des feuilles excel pour traduire les diagrammes paramétriques et contrôler l’impact des changements de valeurs de tel ou tel paramètre. |
2.12.5. En résumé
En résumé l’expression du comportement du système en SysML™ est très similaire à ce qui est fait dans UML™. On retrouve néanmoins le renforcement des liens entre éléments de modèles par les dépendances précises et les allocations. Un autre élément de renforcement entre éléments de modèles concerne le fait qu’un diagramme comportemental (comme une machine à état) est attachée à un élément bien précis (par exemple un bloc). Ces liens apparaissent entre blocs et machines à état, entre cas d’utilisation et diagrammes de séquence ou d’activité, etc.
2.12.6. Questions de révision
-
Quelles sont les différences entre
<<satisfy>>et<<allocate>>? -
Pourquoi est-il important de relier un use case à au moins un requirement ?
-
L’inverse est-il aussi important ?
Partie 4 : Modéliser un système en SysML
1. Une démarche parmi d’autres
Nous allons aborder le développement complet de notre exemple fil rouge en suivant une démarche classique et simple (utilisée par exemple dans [SeeBook2012], où proche de la démarche globale enseignée dans nos cous de DUT Informatique, ou encore proche des documents de référence en la matière [HAS2012], [KAP2007],[FIO2012]) :
-
Spécification du système
-
Conception du système
-
Traçabilité et Allocations
-
Modèle de test
Nous partirons du modèle des exigences produit initialement. Mais avant tout, parlons outils.
1.1. Environnement de développement
Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins).
Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section
est la version 5.2.
Un outil SysML™ seul ne suffit pas (cf. Outils). Il faut penser à la documentation (cf. Génération de documentation).
1.1.1. Outils
Il existe de nombreux outils SysML™. Nous renvoyons le lecteur sur le site de SysML-France pour des informations sur les dernières versions des outils.
1.1.2. Génération de documentation
La plupart des outils permettent de générer de la documentation. Pour les outils basés eclipse comme
TOPCASED, il est possible d’utiliser le plug-in GenDoc2.
Les outils commerciaux comme Rhapsody permettent de générer de nombreux formats.
1.1.3. Animation de modèles et simulation
Fortement liée aux outils, la possibilité d’animer les modèles ou encore d’effectuer des simulations est une exigence de plus en plus forte des ingénieurs systèmes.
Il existe de nombreuses possibilités. Citons par exemple :
- Génération de code VHDL
-
L’outil
RTaWpropose, via génération de code VHDL de simuler les modèles. Voir une démonstration ici. - Simulation en Rhapsody
-
L’outil Rhapsody possède une interface très pratique pour faire du prototypage rapide.
Voir mon tutoriel (en anglais) disponible ici.
- Animation de modèles en Artisan
-
L’outil
Artisanpermet également de faire de l’animation de modèles.
1.2. Spécification du système
Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.
1.3. Conception du système
Chaque cas d’utilisation sera précisé (seq et act).
Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (stm).
Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/
1.4. Traçabilité et Allocations
Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit [7] seront rajoutés en insistant sur les liens :
-
de satisfaction des exigences par les éléments de l’architecture,
-
d’allocation des éléments du modèle fonctionnel vers les éléments logiques,
-
d’allocation des éléments logiques vers les éléments de l’architecture physique.
1.5. Modèle de test
Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.
2. Recettes et bonnes pratiques
La plupart des ouvrages sur un langage enseignent les éléments de ce langage, comme nous l’avons fait à la partie précédente. Nous allons ici partir du principe inverse : comment modéliser tel ou tel partie ou vue de mon système avec SysML. Un peu à la manière des ouvrages du type Cookbook, nous allons donner une liste non exhaustives de recettes. Les choix des éléments de modélisation sont arbitraires ou tirés de discussions (comme ce sera mentionné si c’est le cas).
2.1. Architecture
|
|
Je souhaite modéliser mon système dans son environnement
C’est conseillé. Un block System permet de raccrocher tous les éléments qui le composent à un même niveau.
Dans l’exemple ci-dessous le système (le bloc Pacemaker) est lui-même un simple composant d’un élément de plus haut niveau : le contexte du système (le bloc Context) qui relie alors le système à son environnement.
Voir aussi Conception du système.
|
2.2. Comportement
|
|
Je souhaite modéliser les différents modes (nominal, alternatifs)
Un diagramme d'état peu modéliser les différents modes et les événements qui produisent les changements de mode.
|
Partie 5 : Pédagogie
1. Enseigner SysML
Cette partie est dédiée à l’enseignement à SysML™. J’y distille des conseils et des remarques issues des nombreuses questions soulevées dans le cadre des journées SysML-France ou UPSTI.
1.1. Respect des notations SysML
Je recommande vraiment l’utilisation d’outils (même de dessins, mais dédié à) SysML™. Ils respectent en général la norme OMG SysML v1.3 (bien qu’il faille se méfier). Eviter de "dessiner" des diagrammes.
Par contre la norme permet de faire des adaptations graphiques (cf. la discussion http://www.realtimeatwork.com/2011/08/is-sysml-too-abstract/).
1.2. Diagramme de bloc
Par exemple dans ce diagramme les blocs ne respectent pas la syntaxe graphique de SysML™ :
|
|
Erreur : mauvais symboles graphiques pour les blocs
|
Pour rappel, la notation jmb : Personne permet de représenter un objet (une instance d’une classe ou d’un bloc).
C’est donc une notation utilisée par exemple dans les participants d’un diagramme de séquence ou encore les parties
d’un diagramme interne de bloc.
Donc dans le diagramme ci-dessus, l’acteur est correct (on peut mettre des acteurs dans un bdd, cf. OMG SysML v1.3 p.32), par contre
les objets Block : … est une erreur de notation.
|
|
Solution : utiliser un outil (ici BOUML)
|
|
|
Attention, il est tout à fait possible de représenter des instances dans un bdd (cf. OMG SysML v1.3 p.34), même si c’est très peu courant. |
1.3. Diagramme de séquence
|
|
Erreur : pb avec les participants et la boucle
|
Plusieurs problèmes de non respect de la notation :
-
il manque le rectangle aux participants
-
les participants semblent être des blocs et non des instances
-
la boucle devrait avoir une condition (même "toujours" pour une boucle infinie)
|
|
Le dernier problème est plus une convention qu’une véritable erreur. Cf. Conventions et recommandations. |
1.4. Diagramme des cas d’utilisation
1.4.1. Utilisation du système
|
|
Problème : Fournir n’est pas Obtenir…
|
Il vaut mieux définir les cas d’utilisation du point de vue de (ou des) utilisateurs plutôt que du système. Cf. Conventions et recommandations. Pour rappel, un cas d’utilisation est un regroupement de scénarios qui correspondent à un but d’un des acteurs (dans le domaine du problème considéré et selon la granularité envisagée).
Dans le diagramme ci-dessus il aurait fallut écrire :
|
|
Solution : Prendre le point de vue de l’utilisateur
|
1.4.2. Interaction avec les cas d’utilisation principaux
|
|
Diagramme des Cas d’Utilisation erroné
|
|
|
Erreur : oubli d’interaction
Dans le diagramme Diagramme des Cas d’Utilisation erroné, l’acteur |
|
|
Solution (extrait) : Modifier le diagramme en conséquence
La solution n’est que partiellement satisfaisante (cf. point suivant). |
|
|
J’ai fait disparaître le lien entre |
|
|
L’utilisation de stéréotypes comme |
1.4.3. Utilisation des <<include>>
Il faut faire attention à ne pas abuser des <<include>>.
Par exemple ma recommandation en SysML/UML est de ne jamais avoir ça :
|
|
Problème : mauvaise utilisation de l'
<<include>> |
Dans la figure Problème : mauvaise utilisation de l'<<include>>, il n’y a aucune raison de ne pas inclure le cas d’utilisation
S’identifier directement dans le cas d’utilisation Acheter en ligne. Et avoir ainsi :
|
|
Solution 1 : On englobe les
<<include>> "isolés" |
J’enseigne qu’un <<include>> devrait toujours concerner un cas inclut dans plusieurs autres, comme la figure Solution 2 : On "mutualise" les <<include>> :
|
|
Solution 2 : On "mutualise" les
<<include>> |
Néanmoins je vois deux raisons valables pour décomposer les cas d’utilisation avec des <<include>> qui se retrouvent isolés :
-
Pour indiquer que seulement une partie du cas d’utilisation principal interagit avec un acteur (secondaire la plupart du temps). C’est ce qui est fait dans Solution (extrait) : Modifier le diagramme en conséquence.
-
Pour faire de la décomposition fonctionnelle (cf. point suivant).
1.4.4. Niveau de détails des UC
Faut-il minimiser le nombre de cas d’utilisation ou au contraire détailler? Normalement un bon diagramme des UC est indépendant de la solution, il exprime plutôt le problème (les attentes).
Néanmoins dans le cadre de l’enseignement en prépa comme support graphique à une analyse
fonctionnelle, pourquoi pas détailler. À ce moment-là, utiliser des stéréotypes pour différencier
les cas d’utilisation (<<TopLevel>> et <<Operational>> par exemple comme dans la documentation SysML 1.3 pp 185-186
sur le HybridSUV).
|
|
La question de l’utilisation des cas d’utilisation pour exprimer les activités du système reste à trancher. Le diagramme des activités étant tout de même plus adapté a priori (cf. FAQ). Le principal défaut du diagramme Diagramme des Cas d’Utilisation erroné est surtout de mélanger des cas d’utilisations de niveaux différents. N’oublions pas que derrière chaque UC, il devrait y avoir un but d’une partie prenante. |
1.5. Diagrammes de bloc
1.5.1. Héritage
Attention à la notion d’héritage, complexe à appréhender. On ne peut surtout pas dire :
|
|
Erreur : Confondre héritage et propriété
Un bloc |
La relation doit pourvoir se lire "est un". Or, un SarmentAttaché n’est pas un SarmentNonAttaché (c’est même le contraire)!
Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les points communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes et que l’on créé alors des blocs spécifiques, on parle alors de spécialisation.
On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.
|
|
Solution
Un bloc |
1.5.2. Cardinalités
Attention aux cardinnalités indiquées dans les associations.
|
|
Erreur : Le système est composé de 32 propulseurs!
Il ne s’agit pas d’une erreur de syntaxe SysML, mais d’une erreur de conception.
Un |
|
|
Solution possible
|
1.6. Diagramme d'états
1.6.1. Différence entre UML et SysML sur les machines à état.
SysML a repris (quasiment, cf. plus bas) tel quel le diagramme d'états UML :
|
|
Définition : State Machines (OMG SysML v1.3, p. 189)
SysML reuses many of the major diagram types of UML. In some cases, the UML diagrams are strictly reused, such as use case, sequence, state machine, and package diagrams, whereas in other cases they are modified so that they are consistent with SysML extensions. |
À une exception près, les protocol state machines qui ont été retiré pour des raisons de simplification :
|
|
Définition : State Machines (OMG SysML v1.3, p. 119)
The UML concept of protocol state machines is excluded from SysML to reduce the complexity of the language. |
1.6.2. Lien avec le Grafcet
Le Grafcet étant plus proche des Réseaux de Petri, la correspondance la plus proche serait peut-être le diagramme d’activité.
Voir aussi la FAQ Comment traduire un grafcet en machine à état ?.
1.7. Divers
1.7.1. Du danger d’une lecture trop rapide de la norme
C’est important de faire référence à la norme quand on avance un fait. J’essaye de m’y atteler personnellement dans mes écrits. Néanmoins il faut faire attention car on fait souvent des citations qui finalement ne sont que des extraits.
|
|
Erreur : citation sortie de son contexte
"…[SysML] limite à 1 le nombre de régions dans un état composite (note de bas de page p. [17 de la norme]…)." |
Cette partie de la norme OMG SysML v1.3 mentionne effectivement cette phrase, mais comme un exemple de notes qui peuvent se retrouver dans des manuels d’outils qui ne respecteraient pas la norme justement!!
|
|
Solution : Faire attention au contexte (OMG SysML v1.3, p. 17)
"In the case of “PARTIAL” support for a compliance point, in addition to a formal statement of compliance, implementors, and profile designers must also provide feature support statements." |
Un autre exemple issu d’http://www.uml.org/[UML™] où en fait la norme parle d’une convention adoptée pour ses propres meta-modèles :
|
|
Erreur : citation sortie de son contexte
If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1 (UML Superstructure Specification v2.4.1 p.18). |
Il faut donc bien faire attention avec les extraits de norme.
|
|
Quand on cite un extrait de la norme, citer le numéro de page du document papier et non celui du PDF. |
Partie 6 : Pour aller plus loin
1. Considérations méthodologiques
Exemples de démarche autour de SysML™, (cf. Méthodes et démarches).
2. Analyses et simulation
To be completed
3. Exercices de révision
Reprendre ici les questions des chapitres (à organiser en fichiers!).
3.1. Quizz
3.1.1. Sujet
Un quizz en ligne est disponible ici (me contacter pour le mot de passe).
En voici une capture d'écran :
3.1.2. Corrigé
L’ensemble des questions du quizz a été généré à partir de ce fichier quizz (qui contient les réponses).
3.2. Mots croisés
3.2.1. Sujet
Voici un petit exercice (en anglais pour l’instant, désolé) pour changer :
- Vertical (across)
-
-
2. outside-inside connection
-
4. the full name of a model element is also a … name
-
6. the black diamond in SysML
-
9. History is one of them
-
10. what a block can do
-
13. between states
-
14. a supporter of SysML
-
- Horizontal (down)
-
-
1. used to describe a flow of actions
-
3. message represented by a regular (unfilled) arrow
-
5. each use case is advised to be linked to at least one of them
-
7. they are handled in SysML by Packages
-
8. communication entity in a
sd -
11. a supporter of SysML
-
12. number of diagrams in SysML
-
Annexes
1. Complément sur l’exemple fil rouge bCMS
Le système de gestion de crise doit montrer les suivants propriétés non-fonctionnelles :
1.1. Disponibilité
-
Le système doit être en opération 24 heures par jour, tous les jours, sans interruption, pendant toute l’année, sauf pour un temps d’arrêt maximal de 2 heures tous les 30 jours pour la maintenance.
-
Le système doit récupérer dans un maximum de 30 secondes en cas d'échec.
-
L’entretien doit être reportée ou interrompue quand une crise est imminente sans affecter les capacités des systèmes.
1.2. Fiabilité
-
Le système ne doit pas dépasser un taux d'échec maximum de 0,001%.
-
Les unités mobiles sont en mesure de communiquer avec d’autres unités sur le site crise et le centre de contrôle, indépendamment des conditions d’emplacement, le terrain et la météo.
1.3. Persistance
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les crises : type de crise, l’emplacement de la crise, rapport d’un témoin, emplacement du témoin, les données concernant les témoins, la durée de la crise, les ressources déployées, les victimes civiles, les stratégies utilisées, l’emplacement des équipes de secours sur la crise, journal des communications, et des décisions.
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les ressources disponibles et déployés (à la fois en interne et en externe) : type de ressources (humaines ou équipement), la capacité, l'équipe de sauvetage, l’emplacement, l’heure estimée d’arrivée (ETA) sur le site crise.
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les stratégies de sortie de crise : type de crise, étapes pour résoudre la crise, la configuration des missions nécessaires, des liens vers d’autres stratégies, applications aux crises précédentes, et le taux de succès.
1.4. Sécurité
-
Le système doit définir des politiques d’accès pour les différentes catégories d’utilisateurs. La politique d’accès doit décrire les éléments et informations de chaque acteur peut ajouter, accéder et mettre à jour les informations.
-
Le système doit authentifier les utilisateurs sur la base des politiques d’accès lors de leur premier accès pour accéder aux éléments d’informations. Si un utilisateur reste inactif pendant 30 minutes ou plus, le système doit les obliger à se ré-authentifier.
-
Toutes les communications dans le système doit utiliser des canaux sécurisés conformes avec le cryptage AES-128 standard.
1.5. Mobilité
-
Les ressources de secours doivent pouvoir accéder à l’information sur les mouvements.
-
Le système fournit des informations de localisation utiles pour économiser les ressources.
-
Les ressources de secours doivent communiquer leur emplacement au centre de contrôle.
-
Le système doit avoir accès à des cartes détaillées, des données de terrain et les conditions météorologiques pour l’emplacement de crise et les routes qui y mènent.
1.6. Sécurité
-
Le système doit surveiller les émissions provenant du site crise pour déterminer les distances de fonctionnement sûres pour les ressources de sauvetage.
-
Le système doit surveiller les conditions météorologiques et le terrain sur le site de crise pour assurer la sécurité et le retrait des moyens de secours, et l'évacuation de civils, et les victimes.
-
Le système détermine un périmètre pour le site crise pour assurer la sécurité des civils et l'évacuation des victimes à une distance sûre.
-
Le système surveille les activités criminelles pour assurer la sécurité des moyens de secours, des civils et des blessés.
-
La sécurité du personnel de secours doit avoir la priorité absolue pour le système.
1.7. Adaptabilité
-
Le système doit recommander ou solliciter des ressources alternatives en cas d’indisponibilité ou l’insuffisance de ressources appropriées.
-
Le système doit être en mesure d’utiliser les canaux de communication de rechange en cas d’indisponibilité ou l’insuffisance des moyens existants.
-
Le système doit être en mesure de maintenir une communication efficace dans les zones de perturbation ou de bruit élevé sur le site crise.
1.8. Précision
-
Le système doit avoir accès aux données de la carte, le terrain et les conditions météorologiques avec une précision de 99%.
-
Le système doit fournir des informations à jour pour sauver les ressources.
-
Le système doit enregistrer des données sur la réception sans modifications.
-
La communication entre le système et les ressources de sauvetage doit avoir un facteur de détérioration maximum de 0,0001 pour 1000 km
2. Liens et références utiles
-
Sites officiels
-
Le site de l’association SysML-France
-
Le site de l’http://www.omg.org/[OMG] (Object Management Group)
-
Le portail SysML de l’OMG (Object Management Group)
-
Le site de l’http://www.incose.org/[INCOSE] (International Council on Systems Engineering)
-
Le site de l’http://www.afis.fr/[AFIS] (Association Française d’Ingénierie Système)
-
-
Spécial STI2D et UPSTI
-
Blogs
-
Le site de Tim Weilkiens
-
La démarche Caminao
-
-
Outils SysML
-
Outils de production
-
Les conseils généraux de Scott Ambler sur Ecrire un livre technique
-
Les conseils techniques de Matthew Mc Cullough sur Ecrire un livre technique
-
AsciiDoc comme moteur de base.
-
Pandoc pour la conversion de documents.
-
git-scribe pour la génération des documents à partir d’http://www.methods.co.nz/asciidoc[AsciiDoc].
-
-
Divers
-
Pour en savoir plus sur l’http://jmb.c.la[auteur]
-
3. Le temps et sa prise en compte dans les modèles
Il existe plusieurs façon de représenter les informations temporelles.
SysML™ permet par exemple d’ajouter des contraintes temporelles sur le diagramme de séquence. Il existe deux types de contraintes :
-
la contrainte de durée, qui permet d’indiquer une contrainte sur la durée exacte, la durée minimum ou la durée maximum entre deux événements ;
-
la contrainte de temps, qui permet de positionner des étiquettes associées à des instants dans le diagramme au niveau de certains messages et d’ainsi contraindre leur relation.
Néanmoins, pour une prise en compte industriel des contraintes temporelles, il conviendra d’utiliser le profil dédié à ces aspects : le profil MARTE.
4. Conventions et recommandations
Il existe un certain nombre de conventions complémentaires aux règles formelles de syntaxe que l’on trouve dans la spécification elle-même (rappelées à la fin de cette section). Nous ne les donnons ici qu'à titre indicatif. Il est important pour une organisation qui souhaite utiliser SysML™ comme notation pour ses modèles de se mettre d’accord sur ce type de convention. En voici quelques-unes dans lequel vous pourrez piocher pour définir vos propres conventions.
|
|
Pour les origines UML de certaines conventions, cf. [Styles]. |
4.1. Points de vue
-
Les cas d’utilisation concernent les utilisateurs du système et non le système lui-même. Ainsi les cas d’utilisation
Obtenir les coordonnées actuellesouEnregistrer une tracesont de bons cas d’utilisation d’un GPS. Alors queEconomiser la batterieouCrypter les donnéesne sont pas de bons cas. -
Eviter de placer les matières premières comme des acteurs dans un diagramme d’utilisation, mais plutôt (éventuellement) comme des éléments de diagramme de définition de bloc (principalement celui de contexte).
4.2. Cas d’utilisation et acteurs
-
Placer les acteurs principaux à gauche (e.g., Diagramme des Cas d’Utilisation erroné).
-
Placer les acteurs secondaires à droite (e.g., Diagramme des Cas d’Utilisation erroné).
-
Différencier les acteurs humains (stickman) des autres (stéréotype
<<actor>>) e.g., Diagramme des Cas d’Utilisation erroné. -
Différencier les cas d’utilisation selon :
-
leur importance (e.g.,
<<Principal>>,<<Secondaire>>); -
leur type (e.g.,
<<TopLevel>>,<<Operational>>).
-
4.3. Nommage des divers éléments
-
Les noms de blocs commencent par une majuscule (source : UML™).
-
Les noms de cas d’utilisation (qui représentent une façon d’utiliser le système du point de vue de l’acteur) doivent être un verbe à l’infinitif (source : UML™).
-
Les noms d’activité (qui représentent une action) doivent être un verbe à l’infinitif (source : UML™).
-
Les noms d’attributs commencent par une minuscule et ne sont pas au pluriel (source : UML™).
-
Nommer les "associationEnd" du point de vue du propriétaire et en minuscule (source : [ENS2013]).
4.4. Les requirements
-
Différencier les exigences descriptives et prescriptives. On pourra par exemple utiliser les stéréotypes
<<UserRequirement>>et<<SystemRequirement>>. On pourra aussi définir deux packages différents :DescriptiveRequirementsetPrescriptiveRequirements(source : [SysML4STI2D])
4.5. Les dépendances
-
En général un cas d’utilisation qui n’est inclus (
<<include>>) que dans un seul autre cas est fusionné dans ce dernier. -
Lorsqu’un cas d’utilisation possède plusieurs cas
<<refine>>qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (source : [SysML4STI2D]).
4.6. Blocs et associations
-
Utiliser la référence (faible agrégation) avec parcimonie car c’est un concept complexe à appréhender, surtout pour des non informaticiens (source : [ENS2013]).
4.7. Divers
-
Toujours mentionner les multiplicités pour éviter toute ambiguïté, et de manière plus générale, éviter au maximum de se contenter des conventions par défaut (comme les officielles), sources d’incompréhensions potentielles.
-
Toujours indiquer les conditions des
loop,alt, etc. dans un diagramme de séquence. -
Vérifier la complétude et la non intersection des conditions des transitions sortant d’un même état.
-
Ne pas hésiter à ajouter des légendes (sous forme de notes par exemple) à vos diagrammes un peu complexe.
4.8. Conventions "officielles" (dans la spécification elle-même)
-
Les classes représentées dans un bdd sont par défaut des
<<block>>(source : OMG SysML v1.3, p. 38). -
En l’absence de multiplicité sur les connecteurs, la multiplicité par défaut est "1" de chaque côté (source : OMG SysML v1.3, p. 42).
-
En l’absence de multiplicité sur les associations unidirectionnelles (fléchées), la multiplicité par défaut est "1" (source : OMG SysML v1.3, p. 62).
5. FAQ
Cette FAQ (Frequently Asked Questions) a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions. J’ai aussi ajouté des questions souvent rencontrées dans les journées organisées par SysML-France.
|
|
Voir aussi cette FAQ très bien faite. |
Cette FAQ peut servir de base à la révision d’examens (cf. aussi Exercices de révision).
Quelle est la version courante de la spécification et comment l’obtenir?
Version 1.3 et disponible à l’URL: http://www.sysml.org/docs/specs/OMGSysML-v1.3-12-06-02.pdf
Quels en sont les changements notables depuis la dernière version ?
(en lien avec la question précédente)
Les changements notables par rapport à la 1.2 concernent :
-
synchronisation avec les changements d’UML 2.3
-
le métamodèle de Conjugate ports et sa notation
-
le nommage des activity regions "interruptible"
-
inclusion de UML instance
-
inclusion des structured activity nodes d’UML
-
inclusion des multiple item flow d’UML
-
améliorations du support à Unit et QuantityKind pour les value types, et ajout d’un modèle (non normatif) pour définir les systèmes d’unités et de quantités.
|
|
SysML v1.3 Revision Task Force dirigée par Roger Burkhart et Rick Steiner améliore de manière régulière la spécification en fonction des retours des utilisateurs. |
Quelle est la différence entre les différents ports : proxy, nested, flow, … ?
La version 1.3 a précisé la sémantique des ports et abandonne le concept de flow specification
au profit d’une description via un bloc possédant des flow properties (cf. Flow properties).
Ainsi :
-
Les ports par défauts (hérités d’UML™) permettent d’indiquer des services fournis et requis.
-
Les ports de type flot (flow) spécifient que quelque-chose "circule" dans ou depuis un bloc.
-
Si le bloc représentant le port possède lui-même des ports, on parle alors de nested ports (cf. Nested Ports).
-
Enfin, un proxy port permet de donner accès à l’extérieur d’un bloc à l’un des ports de l’un de ses composants.
Qu’est-ce que la certification SysML et comment la passer?
Les informations sur la certification sont sur le site dédié de l’OMG™.
La certification (qui coûte environ 300€ par niveau) permet de garantir que celui qui la possède maîtrise la notation. Il faut actuellement s’inscrire via le site de Pearson Vue.
|
|
Il faut vraiment maîtriser les concepts eux-même (le métamodèle), et pas seulement avoir une bonne pratique. De plus, il faut également bien maîtriser l’anglais car les questions/réponses sont en anglais et leur formulation peut comporter des pièges. Pour vous tester sur le méta-modèle, vous pouvez vous tester sur le quizz réalisé par Loïc Féjoz : http://www.realtimeatwork.com/2010/06/test-quizz/ |
Peut-on avoir un requirement contenu plusieurs fois ?
Non. Le lien de containment est en fait une action qui place le "contenu" dans le
"contenant". Dans TOPCASED, le diagramme laisse les liens précédents à l'écran, mais dans
le modèle, c’est bien le dernier containment réalisé qui est pris en compte. Dans
la figure ci-dessous le lien A-C a été "dessiné" après celui B-C.
|
|
Ce "bug" provient du fait que le lien de containment n’est pas un lien de dépendance, mais plutôt une représentation graphique de la contenance. |
Comment alors peut-on "partager" un requirement ?
(En lien avec la question précédente)
L’organisation SysML™ des requirements est en fait un arbre. Pour réaliser ce "partage" certains utilisent un lien <<copy>> pour créer plusieurs copies d’un même requirement. Personnellement je n’aime pas cette solution.
|
|
Définition : Réutilisation d’exigences (OMG SysML v1.3, Fig.16.6, p. 152)
…the use of the Copy dependency […] allow a single requirement to be reused in several requirements hierarchies. |
Peut-on avoir un lien <<satisfy>> entre exigences?
Techniquement oui (<<satisfy>> étant dérivé de <<dependency>>), mais ça n’a pas beaucoup de sens que de dire qu’un besoin est satisfait par un autre. Il s’agit le plus souvent d’un lien <<deriveReqt>>.
|
|
Certaines méthodes utilisent ce lien pour par exemple exprimer qu’une exigence cliente est satisfaite par une exigence système (comme la méthode [Harmony]). |
Quelle est la différence entre <<deriveReqt>> et <<refine>> ?
La norme n’impose pas de sémantique précise à <<deriveReqt>>. Il y a généralement deux interprétations.
-
Un usage classique est de l’utiliser pour ajouter des exigences plus détaillés déduites à partir d’autres exigences. Un exemple issue de la norme est une exigence de
puissance moteurdéduite (deriveReqt) depuis l’exigence sur l’accélérationd’un véhicule. -
Une vision plus stricte, aussi illustré par l’exemple précédent, est que l’exigence dérivée est une condition nécessaire (un pré-requis) à l’exigence cible.
Autre exemple respectant 1 mais pas 2 : "Le véhicule doit posséder 4 roues." est dérivé de "Le véhicule doit se déplacer sur route." En effet, un aéroglisseur répondrait aussi l’exigence initiale et n’a pourtant pas de roues.
Quant au <<refine>> il est utilisé pour indiquer qu’un élément de modèle (qui peut être lui-même un requirement) est un raffinement (au sens niveaux d’abstraction, du plus abstrait au plus concret) d’un requirement. Par exemple, un use case ou un diagramme d’activité peut être un raffinement d’une exigence fonctionnelle (textuelle par exemple).
A quoi sert le lien <<trace>> ?
Il est utilisé pour indiquer que l’on souhaite conserver un lien de traçabilité entre les éléments
(par exemple entre un élément de modélisation et un document). Il est recommandé d’utilisé une de ces
versions plus précises (<<deriveReqt>> ou <<satisfy>> par exemple).
Comment SysML permet-il la validation et la vérification des exigences ?
Comment SysML™ permet de vérifier et de valider les exigences ?
La validation d’une exigence est de la responsabilité des parties prenantes. À partir de la spécification des exigences, ils valident qu’il s’agit bien du bon produit à construire. Typiquement, le diagramme des exigences sert de base à cette validation.
La vérification d’une exigence est de la responsabilité de l’ingénieur système et/ou de l’analyste système.
C’est à eux de montrer la correspondance entre les éléments constituant du système et les exigences spécifiées.
C’est principalement pour cette activité que sont utilisés les relations <<satisfy>> et <<verify>>.
À quoi sert un diagramme des UC avec un seul cas d’utilisation ?
Tout simplement à relier les autres diagrammes à ce cas d’utilisation. Par exemple le comportement
du système, l’architecture, etc. (les solutions) pourront être reliées (<<satisfy>>) à ce cas.
Il faut aussi ne pas perdre de vue qu’un diagramme peut évoluer. On pourra très bien rajouter au
diagramme des cas non encore pris en compte comme Transporter le système, Recycler le système, etc.
Comment faut-il comprendre "interaction" dans les diagrammes d’UC ?
La définition de la norme OMG SysML v1.3 :
|
|
Définition : Actors (OMG SysML v1.3, p. 123)
… Actors represent classifier roles that are external to the system that may correspond to users, systems, and or other environmental entities. They may interact either directly or indirectly with the system … |
Pour la comprendre il ne faut pas utiliser le Larousse français (qui rend presque le caractère réciproque obligatoire), mais plutôt la comprendre dans son acceptation informatique (comme dans "Interaction Homme-Machine"). Par exemple un message (appel de méthode) d’un élément vers un autre dans un diagramme de séquence est appelé en SysML™ une interaction.
SysML™ permet de préciser le caractère réciproque ou non de l’interaction par exemple entre un Acteur et un Cas d’utilisation :
Les "matières premières" font-elles parties des acteurs ?
On pourrait les considérer comme des acteurs en se fiant à la définition (cf. Acteurs) et en les associant à des environmental entities. Mais elles sont échangées avec les entités de l’environnement, ce qui n’est pas la même chose. Autrement dit, il faut indiquer qui fournit les matières premières et qui recueille les matières produites éventuellement en tant qu’acteurs, pas les matières elles-même, qui seront représenter comme des flux échangés ou des blocs. Eventuellement on peut les retrouver dans le diagramme de contexte ou encore dans un diagramme structurel comme le diagramme de bloc interne.
|
|
Je recommande la lecture (anglaise, sorry) de l’excellent plaidoyer pour la mort des acteurs : http://model-based-systems-engineering.com/tag/sysml/. |
|
|
Donc non, le soleil et le vent ne sont pas des acteurs!! (ni la corde, ni la raquette) |
Pour l’analyse fonctionnelle : diagramme des UC ou des activités ?
Pour alimenter le débat, je renvois aux exemples donnés par Loïc Féjoz lors de la journée UPSTI. Voici un diagramme classique FAST :
Quelle est la différence entre un join de type "OU" et un fusion dans un diagramme d’activités ?
Pour rappel le join est utilisé pour représenter la synchronisation (le "rendez-vous") et
représente donc une conjonction "ET". Mais le comportement par défaut pouvant être modifié par
un <<joinSpecification>>, on peut indiquer un "OU" pour signifier l’attente d’un seul des deux jetons.
Mais justement le fusion est là pour ça normalement. Ces 2 concepts étant issus d’http://www.uml.org/[UML™], il
nous faut nous référer à la norme de ce dernier:
|
|
Définition : Types de diagrammes (UML Superstructure v2.4.1 p. 399)
All tokens offered on incoming edges are offered to the outgoing edge. There is no synchronization of flows or joining of tokens. |
Il n’y a donc sémantiquement aucune différence.
|
|
Attention, il n’y a pas beaucoup de sens à utiliser un join de cette façon, car non seulement il ne "joint" plus rien, mais en plus contrairement à un join qui "consomme" les 2 jetons, une telle utilisation aurait pour effet de laisser les 2 jetons passer, mais l’un après l’autre! |
Un système peut il avoir plusieurs états?
On lit souvent qu’il n’y a pour un système ou un composant "qu’un seul état actif à la fois".
Du point de vue structurel, si l’on considère que l'état à un instant t d’un composant est représenté par
la valeur de ses attributs à cet instant, alors cette composition est unique. Néanmoins cela prête souvent
à confusion avec le fait qu’un composant dont le comportement est décrit par une machine à état avec des
régions concurrentes peut se retrouver dans plusieurs états (SysML™ du coup) en même temps.
Il faut donc bien faire la différence entre :
-
l'état du système (en tant qu’association de valeurs d’attributs à un instant T) qui lui est unique à un instant donné, et
-
l'état d’une machine à états (en tant qu’abstraction d’un ensemble d'états au sens précédent).
|
|
Exemple d’un système ayant plusieurs états, au sens des machine à états (fourni par mailto:loic.fejoz@realtimeatwork.com[Loïc Féjoz])
Soit un système avec une unique variable |
Comment traduire un Grafcet en machine à état ?
En automatique, la notation la plus connue pour représenter la dynamique d’un système est le Grafcet. Il semble qu’il existe une synthèse du passage Grafcet ⇒ diagramme d'état. J’attends de le trouver pour l’intégrer ici. Car sans en être un spécialiste, ce que j’en ai lu me fait plutôt penser à un diagramme d’activité (notamment par leur proximités à tous les deux avec les Réseaux de Petri).
Divers
Quelques autres questions que je laisse à votre sagacité :
-
Pourquoi les ingénieurs systèmes auraient-ils besoin d’un n-ième langage de modélisation ?
-
Quelles sont les relations entre “open source SysML” et “OMG SysML” ?
-
Quelle est la feuille de route pour SysML 2.0?
-
Quelles sont les relations entre UML et SysML? Peut-on les utiliser ensemble?
-
Peut-on "customizer" SysML?
-
Quel langage est le plus facile à apprendre, SysML ou UML?
FABQ
Cette Frequently Asked Bad Questions est une compilation des questions trouvées parfois dans les forums et qui montrent l’incompréhension qui entoure encore SysML™.
Comment installer SysML?
SysML™ n’est pas un programme qu’on installe. Il existe de nombreux outils qui chacun possède sa propre façon d'être installé sur votre machine (en fonction de votre système d’exploitation, si c’est un plugin, etc.).
Comment exécuter un diagramme SysML?
Les diagrammes SysML™ ne sont que des dessins, des représentations graphiques, ils ne s'exécutent donc pas. Bien sûr de nombreux travaux et outils portent sur les modèles exécutables. Il s’agit alors pour un outil de proposer de reproduire la dynamique d’un diagramme. Il s’agit en général de diagramme de comportement (par exemple une machine à état) pour lequel l’outil propose de simuler l’arrivée d'événement et de reproduire (plus ou moins graphiquement) le comportement modélisé (par exemple le franchissement d’une transition).
6. Références
Voici quelques références utiles.
-
[ENS2013] L. Gendre et J.-M. Virely, SysML. Tutoriel du 13/06/2013. ENS Cachan.
-
[FIO2012] Fiorèse S., Meinadier J., Découvrir et comprendre l’ingénierie système, AFIS 2012.
-
[FMS] A. Moore, R. Steiner, S. Friedenthal, A Practical Guide to SysML, The MK/OMG Press, MK/OMG Press, 2011 (2nd edition).
-
[HAS2012] Haskins C., SE Handbook Working Group, INCOSE Systems Engineering Handbook: Version 3.2.2, International Council on Systems Engineering, 2012.
-
[KAP2007] Kapurch S., NASA Systems Engineering Handbook, 2007 (pdf).
-
[REQ2012] Guide Bonnes Pratiques en Ingénierie des Exigences, AFIS 2012.
-
[Roques2010] Pascal Roques. SysML par l’exemple - Un langage de modélisation pour systèmes complexes. Eyrolles. À acheter ici.
-
[SeeBook2012] Embedded Systems Analysis and Modeling with SysML, UML and AADL, F. Kordon, J. Hugues, A. Canals, A. Dohet, Wiley, 2013.
-
[Sommerville1997] Ian Sommerville, Pete Sawyer. Requirements Engineering: A Good Practice Guide. Wiley, 1997.
-
[SysML] OMG. Systems modeling language version 1.3. Technical report, 2012.
-
[taoup] Eric Steven Raymond. The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9.
-
[Walsh1999] Norman Walsh & Leonard Muellner. DocBook - The Definitive Guide. O’Reilly & Associates. 1999. ISBN 1-56592-580-7.
-
[Harmony] Bruce Powel Douglass. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development. Addison-Wesley Professional, 2009. ISBN-10: 0-321-54549-4
-
[Styles] Scott W. Ambler. The Elements of UML 2.0 Style. Cambridge University Press, 2005. ISBN: 0-521-61678-6
-
[Fowler2004] Martin Fowler. UML 2.0 INFORMATIQUE PROFESSIONNELLE, 2004.
-
[Fejoz2013] Loïc Fejoz. SysML4STI2D, présentation de SysML en STI2D, 2004. Disponible ici.
-
[OMG2009] The Current State of Model Based Systems Engineering: Results from the OMG SysML Request for Information. Mary Bone and Robert Cloutier, 2009. Disponible ici.
7. Glossaire
Acronymes SysML
act-
Raccourcis pour Diagramme d'ACTivité dans une cartouche SysML™
bdd-
Raccourcis pour Block Definition Diagram dans une cartouche SysML™
dss-
Diagramme de Séquence Système (un
sdoù seul le système dans sa globalité est représenté [8]) ibd-
Raccourcis pour Internal Block Diagram dans une cartouche SysML™
par-
Raccourcis pour Parametric Diagram dans une cartouche SysML™
pkg-
Raccourcis pour PaKaGe Diagram dans une cartouche SysML™
req-
Raccourcis pour REQuirements Diagram dans une cartouche SysML™
sd-
Raccourcis pour SEQquence Diagram dans une cartouche SysML™
stm-
Raccourcis pour STate Machine dans une cartouche SysML™
uc-
Raccourcis pour Use Case Diagram dans une cartouche SysML™
Définitions générales
|
|
Ressources
Les définitions ci-dessous sont regroupées à titre indicatif. Je vous invite à consulter les sources suivantes :
|
- DRY
-
Don’t Repeat Yourself : Un bon principe qui veut qu’on évite de répéter des tâches manuelles (comme les tests) en utilisant plutôt des scripts et des programmes.
- EIA
-
Electronic Industries Alliance : un organisme de standardisation (voir EIA.
- FAQ
-
Frequently Asked Questions : une liste de questions souvent posées (et les réponses correspondantes) sur un thème donné.
- IEEE
-
Institute of Electrical and Electronics Engineers : une "société savante" américaine très influente en matière de standards (voir IEEE.
- INCOSE
-
International Council on Systems Engineering : Une organisation fondée en 1990 pour faire avancer les technologies d’Ingénierie Système.
- IPT
-
Integrated Product Team : Une équipe classique en développement système.
- ISO
-
International Organization for Standardization : Le leader mondial des normes (voir ISO.
- OMG
-
Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).
- TDD
-
Test Driven Development : Développements dirigés par les tests. On écrit les tests avant d'écrire le code. On travaille son code tant que les tests ne passent pas.
- TRL
-
Technology Readiness Level : Système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).
- STI2D
-
Sciences et Technologies de l'Industrie et du Développement Durable : série du baccarauléat qui met l’accent sur les technologies transversales et qui a introduit en 2011 l’enseignement de SysML™.
- SysML
-
System Modeling Language ™ : Le langage de modélisation de systèmes maintenu par l’OMG™.
- UML
-
Unified Modeling Language ™ : Le langage de modélisation généraliste maintenu par l’OMG™.